Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow no-console development #2008

Merged
merged 4 commits into from
Dec 19, 2017
Merged

Conversation

alwaysblank
Copy link
Member

So far as I can tell, .eslint files don't allow for internal conditionals, so this PR implements a "production" eslint file that is used when the production flag is set. Otherwise, it uses package.json. I structured it this way so that text editors will hopefully not be confused about which eslint file to read rules from. Rules can also be directly passed in the webpack config, but I felt that this would scale poorly and a separate file makes things a bit easier to understand. This change would also allow for easy customization for other dev vs prod eslint rules.

This would resolve issue #2006.

…ag is set on `yarn build`, in which case it will throw an error.
@swalkinshaw
Copy link
Member

swalkinshaw commented Dec 18, 2017

.eslintrcProd should probably be .eslintrc.production.js. ref: https://eslint.org/docs/user-guide/configuring#configuration-file-formats

@mAAdhaTTah
Copy link

If you make it .eslintrc.js, I feel like you should be able to add conditionals, but I haven't done it myself.

@swalkinshaw
Copy link
Member

Yeah I did wonder that if we're adding an actual file, then maybe all the others should be moved from package.json in they're own file too. So we either use conditionals, or two files.

@alwaysblank
Copy link
Member Author

IMO I'd lead toward two files (i.e. .eslintrc and .eslintrc.production.json): It seems cleaner and easier to understand, and makes it very clear where rules go.

@LeoColomb
Copy link
Contributor

LeoColomb commented Dec 18, 2017

It seems more common to have a single .eslintrc.js.
(See some popular examples)

@mAAdhaTTah
Copy link

mAAdhaTTah commented Dec 18, 2017

I think taking that logic to the extreme would make things more confusing, especially cuz if you wanted to add the rule to both, you now have to add it in two places, which is going to be the more likely update. Generally speaking, throughout Sage, you have single files with conditionals based on the env (e.g. the webpack build has this, and I think that's more common and easier to understand.

As a comparison, I just started a project with Create React App and ejected, and found two separate webpack configurations, and I kinda hate it. Once I start tinkering around in there, I feel like I'm doing everything twice (not to mention it feels kind of over engineered for my purposes, but that's a separate issue).

@swalkinshaw
Copy link
Member

One of Sage's goals is to keep dev and prod as close as possible. Using a single file would probably encourage this. Right now there'd only be a single difference (debugger related things).

…nditionals in the config file itself, significantly simpliying rule creation. For small-scale differences, this seems to be the simplest solution.
@alwaysblank
Copy link
Member Author

Solid arguments, my bad for not digging a bit deeper initially. Setting conditionals inside .eslintrc.js is perfectly easy, and VS Code picks them up just fine. This update to the PR implements the solution that seems to be the consensus.

@@ -20,6 +20,7 @@ const config = merge({
root: rootPath,
assets: path.join(rootPath, 'resources/assets'),
dist: path.join(rootPath, 'dist'),
eslintProd: path.join(rootPath, '.eslintrc.production.json'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥

Copy link
Member

@swalkinshaw swalkinshaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@retlehs retlehs merged commit 42db9f9 into roots:master Dec 19, 2017
@alwaysblank alwaysblank deleted the allow-console-on-dev branch December 19, 2017 17:12
oxyc added a commit to generoi/sage that referenced this pull request Jan 8, 2018
* upstream/master:
  Don't need this any more! :(
  This moves our eslint config in .eslint.js, which allows us to use conditionals in the config file itself, significantly simpliying rule creation. For small-scale differences, this seems to be the simplest solution.
  Rename production eslint file from `.eslintrcProd` to `.eslint.production.json` as per suggestion from @swalkinshaw: roots#2008 (comment)
  Build process now allows console.log, except when the `production` flag is set on `yarn build`, in which case it will throw an error.
  Delete .eslintrc
  Remove some Bower traces
  Update README.md
  Add Code of Conduct [ci skip]
  Change .dev to .test for default local dev TLD per roots/trellis#923
  Bootstrap function in _variables.scss to play nice with other frameworks
  Move variables and Bootstrap imports to autoload
  Remove explicit Bootstrap lines
  Example $theme-color
  Update main.scss
  Update controller examples
  Update dependencies
  Update CHANGELOG [ci skip]
  Bootstrap 4 Beta 2
  Remove get_the_posts_navigation from 404
ptrckvzn added a commit to ptrckvzn/sage that referenced this pull request Jan 30, 2018
* sage/master:
  Updated bootstrap to release version 4.0.0 Updated popper.js to version 1.12.9
  Add php-mbstring to list of requirements
  Don't need this any more! :(
  This moves our eslint config in .eslint.js, which allows us to use conditionals in the config file itself, significantly simpliying rule creation. For small-scale differences, this seems to be the simplest solution.
  Rename production eslint file from `.eslintrcProd` to `.eslint.production.json` as per suggestion from @swalkinshaw: roots#2008 (comment)
  Build process now allows console.log, except when the `production` flag is set on `yarn build`, in which case it will throw an error.
  Delete .eslintrc
  Remove some Bower traces
  Update README.md
  Add Code of Conduct [ci skip]
  Change .dev to .test for default local dev TLD per roots/trellis#923
  Bootstrap function in _variables.scss to play nice with other frameworks
  Move variables and Bootstrap imports to autoload
  Remove explicit Bootstrap lines
  Example $theme-color
  Update main.scss
  Update controller examples
ashleyrevlett added a commit to relaydesignco/sage that referenced this pull request Feb 14, 2018
* master: (339 commits)
  Update CHANGELOG.md
  9.0.0
  Update README [ci skip]
  Update CHANGELOG [ci skip]
  npm lockfile
  Update dependencies
  Updated bootstrap to release version 4.0.0 Updated popper.js to version 1.12.9
  Add php-mbstring to list of requirements
  Don't need this any more! :(
  This moves our eslint config in .eslint.js, which allows us to use conditionals in the config file itself, significantly simpliying rule creation. For small-scale differences, this seems to be the simplest solution.
  Rename production eslint file from `.eslintrcProd` to `.eslint.production.json` as per suggestion from @swalkinshaw: roots#2008 (comment)
  Build process now allows console.log, except when the `production` flag is set on `yarn build`, in which case it will throw an error.
  Delete .eslintrc
  Remove some Bower traces
  Update README.md
  Add Code of Conduct [ci skip]
  Change .dev to .test for default local dev TLD per roots/trellis#923
  Bootstrap function in _variables.scss to play nice with other frameworks
  Move variables and Bootstrap imports to autoload
  Remove explicit Bootstrap lines
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants